Plantage à la mise à jour 2.5.28 vers 3.4

[PascalBFC25]

Re : Plantage à la mise à jour 2.5.28 vers 3.4

Bonsoir,

Je n'ai pas essayé cette méthode mais je vais le faire demain.
Je craignais que la désinstallation des extensions supprimait également les tables.

Ce sont peut-être les extensions non compatibles avec J3 qui font planter le système.
Je vais donc restaurer le site 2.5.28 sur mon serveur local et faire la manip.

Je m'apprêtais à mettre à jour les tables de mon upgrade avorté avec les fonctions J3.4 mais c'est fastidieux, surtout que certains ID se télescopent, comme précisé plus haut !

Merci pour la procédure, cela va me donner des pistes car j'ai le même type d'erreur dans le fichier error.php de mon hébergeur !
Je reviendrai dire ici où j'en suis !

[roland_d_alsace]

Re : Plantage à la mise à jour 2.5.28 vers 3.4

Hello.

Le logs/error.php à la racine du site est ecrit par Joomla.
Il est donc assez normal qu'il contienne les même messages que ceux affichés.

Les logs d'apache (error.log situé plus haut que la racine des sites dans l'arborescence serveur) peuvent contenir d'autres informations très utiles.

Un composant pas à jour, ou même un module ne devrait pas trop poser de problème lors de l'ugrade.

C'est plutôt la configuration serveur (minimas requis) mais si tu arrive à faire tourner un J3.4 tout neuf, ce n'est pas là que se situe le problème.
Ensuite il y a les limites du php.ini qui ne doivent pas être trop basses, mais ceci devrait laisser des traces dans les logs d'apache (memory_limit, max_input_var, max_execution_time -> surtout sur serveur local, post_max_size -> pour info le paquet de maj de joomla depasse les 8M).
Et surtout les plugins système qu'il faut bien "pointer".

Pour phocadownload, je te conseille quand même de sauvegarder les tables du composant (toutes les tables avec nom commençant par #_phocadownload avec phpmdyadmin par exemple) avant de désinstaller le composant.

Concernant ton erreur

Bonjour à tous,
Voici le dernier message d'erreur que j'ai dans mon fichier error.php :

[06-Mar-2015 22:32:07 Europe/Paris] PHP Fatal error: Call to a member function set() on a non-object in /data/www/e7dcb6fb0522dac4ba2cb3611f394767/ftp/web/administrator/components/com_login/controller.php on line 36

Je l'ai aussi eu.
C'est un problème sur le contrôleur principal d'un composant sur une instruction $this->input->set('view', 'login').
J'ai traqué l'erreur pour constater des différences dans les bibliothèques de Joomla.
Il est probable qu'un composant ait fait des modifications (rajouts) dans ce dossier du core de Joomla.

Le correctif est de renommer /librairies/joomla en /librairies/joomla-old, et de reprendre le dossier /librairies/joomla d'une install de joomla 3.x de même version et fonctionnelle.

J'ai eu ce problème sur un assez gros site démarré sous J1.6.

Je ne l'ai eu qu'une seule fois, je n'ai donc pas fait d'info sur mon site...
Du coup je vais le faire, car il a été suivit par un autre problème assez voisin.

Espérant que cela puisse t'aider.

[PhMi]

Re : Plantage à la mise à jour 2.5.28 vers 3.4

J'ai mis en ligne la procédure que j'ai utilisée lors de la migration de mes sites.
Elle est accessible ici...

Merci de ces précisions : c'est la première fois que je lis toute une série de recommandations préliminaires (site hors ligne, rapport d'erreur, cache, SEO, catégories, bd, … ). Je comprends qu'il faut présenter une version 2.5 aussi propre que possible.

A tenter une prochaine fois !

[jisse03]

Re : Plantage à la mise à jour 2.5.28 vers 3.4

Bonjour,

Il m'est arrivé sur une mise à jour ce type de problème. La procédure s'était arrêtée avant le fin complète, et il restait des scories de 2.5.
Comparer les répertoires include et libraries d'une version propre de 3.4 et supprimer les doublons qui peuvent rester de 2.5.

[PhMi]

Re : Plantage à la mise à jour 2.5.28 vers 3.4

Bonjour Jisse03,

Il n'y a pas de doute que le passage de 2.5 à 3.4 ne se fait pas toujours (souvent ? rarement ?) sans avoir besoin de repérer (comment ?) ce qui n'a pas été transformé … au moins pour moi …

[PascalBFC25]

Re : Plantage à la mise à jour 2.5.28 vers 3.4

Bonsoir à tous,

Je progresse.
J'ai découvert que j'avais des extensions non compatibles avec V3, dont je ne me rappelais plus la présence (HD article et Sigplus...)
J'ai réinstallé le site en 2.5.28 en local, sauvé les tables des extensions, désinstallé toutes les extensions, et réussi à le migrer en V3.4 avec Akeeba CMS update.

J'ai ensuite réinstallé toutes les extensions dont j'ai besoin, il faut maintenant que je mette à jour les tables de la base de données, ICagenda est vide, par exemple.
Le backend tourne normalement, le frontend est à compléter, il faut notamment reconstruire les liens des extensions supprimées, mais le progrès est notable !!!

J'ai beaucoup progressé grâce à vos conseils !

Je vais faire la même manip sur le nouveau serveur de mon hébergeur.

[PascalBFC25]

Re : Plantage à la mise à jour 2.5.28 vers 3.4

Bonjour,

Et bien voilà, le problème est réglé. La mise à jour plantait car des extensions que j'avais oubliées n'étaient pas compatibles avec la V3.4. (HD article et Sigplus, entre autres...).

En suivant vos conseils, voilà comment j'y suis arrivé.

J'ai :

Installé un serveur sur mon PC, avec la version complète de mon site en production. V2.5.27.
Migré ce site en 2.5.28 (A mon avis ,pas forcément obligatoire, mais bon...)
Sauvegardé toutes les tables de ma base de données concernant les extensions (IC Agenda, Chronoforms, Phocadownload).
Sauvegardé mes formulaires chronoforms avec l'outil intégré à l'extension.
Désinstallé toutes les extensions non-natives joomla.
Installé Akeeba CMS update, puis lancé la montée de version avec cela.

La montée de version s'est bien passée, quoique franchement longue, la page de download d'Akeeba est restée un bon moment sans bouger...
Quand j'ai eu de nouveau l'accès au backend et frontend, j'ai sauvegardé toutes mes tables de la BD contenant les données.

Sur mon serveur en ligne, chez mon hébergeur, site en pré-production (je changeais de serveur...), j'ai installé une version complète, vierge, de J3.4, avec toutes les extensions nécessaires (IC Agenda, Chronoforms, Phocadownload), compatibles.
J'ai transféré aussi le template beez2 de l'ancien serveur.

J'ai ensuite transféré toutes les tables de la base de données de mon serveur local (V3.4 migré depuis V2.5.28) vers le serveur distant.
J'ai ré-importé les formulaires Chronoforms V4 dans V5, avec l'outil adéquat.
Le site distant fonctionne, il me reste à recréer certains liens qui ont été perdus et à reconfigurer les nouvelles extensions.
Certaines extensions ne sont pas encore complètement opérationnelles (IC agenda et Chronoforms V5), à creuser.

Mais globalement, je suis arrivé au bout, je pense.

Merci encore pour l'aide apportée par chacun d'entre vous, j'en retiens qu'il faut de la rigueur et bien dérouler les opérations dans le bon ordre. Les infos et liens contenues dans ce topic m'ont permis d'y arriver !

[PhMi]

Re : Plantage à la mise à jour 2.5.28 vers 3.4

Patience et longueur de temps font mieux que rage et précipitation …

[PascalBFC25]

Re : Plantage à la mise à jour 2.5.28 vers 3.4

Oui !

Pendant que j'y suis, je complète avec mes dernières infos concernant les extensions ICagenda et Chronoforms.
Pour ICagenda, j'avais migré les tables spécifiques (ICagenda_events et ICagenda_category) mais l'affichage des évènements ne fonctionnait pas. Par contre, les évènements et les catégories d'évènements étaient accessibles et modifiables dans le backend.

Pour que cela fonctionne, il faut forcer la langue à "tous" (ou autre) et vérifier que dans la table ICagenda_events de la base de données, la colonne langage possède un * (astérisque) ou un titre de langue. si la colonne langue est vide, l'évènement ne s'affiche pas dans la liste des évènements, ni à partir du pop-up ouvert quand on clique sur le jour concerné dans le calendrier, ni si on appelle la fonction ICagenda view list.

Ensuite, vous allez remarquer que la localisation Maps ne fonctionne pas, la carte ne s'affiche pas.
Pour corriger cela, il faut réenregistrer chaque évènement, sans le modifier, ce qui provoque le remplissage automatique des coordonnées de latitude et de longitude dans les bonnes colonnes de la table _events.
Dans la version précédente d'ICagenda, les coordonnées étaient stockées dans une seule colonne.
On peut le faire manuellement via phpmyadmin en séparant les deux coordonnées mais c'est fastidieux ! Je l'ai fait.
Le fait d'avoir les données à la fois dans la colonne "coordonnées" et les colonnes "latitude" et "longitude" ne gêne pas le fonctionnement. Mais il faut que les colonnes "latitude" et "longitude" soient remplies.

Pour Chronoforms, j'avais installé la version V5. Réimporté mon formulaire V4 / J2.5 via la commande d'importation mais celui-ci ne fonctionnait pas.
J'ai donc désinstallé la V5 et installé la V4 pour J3.x, réimporté le formulaire et mis à jour les liens correspondants.
Le formulaire est devenu pleinement opérationnel. Cette solution a été plus rapide que de refaire le formulaire dans la V5 de Chronoforms.